Traditional telephony solutions which were previously delivered by circuit switched telephony applications are increasingly being provided by Voice over Internet Protocol (VoIP) applications. Examples of circuit switched telephony applications include the Public Switched Telephone network (PSTN) for carriers and Private Branch Exchanges (PBXs), Key Systems and Centrex applications for enterprises.
The enterprise solutions typically provide 2 major advantages. First they allow an enterprise to provide telephone access for its members without requiring a separate outgoing line to the PSTN for each member. In other words, they allow a several members to share Network Access Resources (for example, external telephone lines). Second, they typically provide a larger set of features to its members.
As stated, VoIP is now being used to provide telephony. This is being implemented for several reasons. For example, consumers have found that VoIP calls are not subject to long distance telephone charges. Enterprises previously required separate voice and data networks, which can now be integrated. Furthermore, non traditional telephone operators can now provide telephony services to their subscribers using data networks (e.g., cable operators).
Accordingly, protocols for VoIP call set-up have been developed which typically require signaling between the endpoints of a call, and the endpoints are typically involved with each call set-up. Examples of such protocols are H.323, Session Initiation Protocol (SIP) and MGCP. As will be appreciated by a person skilled in the art, voice is typically carried using Real-Time Transport Protocol (RTP) over UDP/IP.
As described above, one of the advantages of PBXs and Key Systems is the ability to share Network Access Resources. This is also desirable for computers and other IP devices on a Local Area Network (LAN) which require communication with the Internet. Thus, for example, several computers connected on a LAN can share one or more access lines (e.g., DSL, cable or T1) for internet access. One of the key Network Access Resources are IP addresses. In order to transmit data between devices using IP, each IP device involved in a session needs a unique IP address. Network Address Translation devices (NATs) allow for the sharing of external IP addresses. Each device on the Private (enterprise or residential) side of a NAT is allocated an IP address. However, such an IP address is not in fact unique. Although it is not repeated within the LAN connected to the NAT, the same address can be allocated to many other devices by other NATs. The NAT itself is provided with one or more external IP addresses, which are unique. IP packets destined to a device behind a NAT are sent to the NAT's external IP address, which is then routed to the private IP address of the device.
However, introducing Network Address Translation devices (NATs) into an IP network complicates the establishment of voice streams carried within RTP. RTP is used to carry voice in a packetized form in an IP network. However unsolicited inbound RTP streams can not generally traverse a NAT. This is due to the fact that the signaling protocols used in conjunction with RTP refer to the private IP address of the RTP endpoint. This private IP address is typically unreachable by the other endpoint which is part of the conversation. This is called the media NAT traversal problem. One approach for solving this problem is to introduce another network element that is able to modify signaling messages to cause the devices behind a NAT to send an RTP stream to a known IP address, and use the source IP address from the packets received to send packets back to the actual intended destination or device. An example of such a network element used by Service Providers (hereafter “Carriers”) for a number of protocols (SIP, MGCP and H.323) is a generic class of products called Session Border Controllers (SBCs), which are typically implemented at the customer border of the Carrier network. A discussion of this NAT traversal problem, and solutions, is included in a White Paper by Newport Networks, NAT Traversal for Multimedia over IP Services—2006, http://www.newport-networks.com/cust-docs/33-NAT-Traversal.pdf, the contents of which are hereby incorporated by reference in their entirety. An SBC includes an RTP proxy. An RTP proxy is an entity which relays RTP streams between two endpoints. One application of an RTP proxy is NAT traversal where the RTP proxy learns the destination to which it should relay the RTP stream by identifying the source of the other side of the stream. A document which describes how an RTP proxy is used for NAT traversal is U.S. Pat. No. 7,006,436, the contents of which are also hereby incorporated by reference in their entirety.
While an SBC solution works for SBC-supported standard protocols (SIP, MGCP and H.323), such a solution has limits because SBCs do not support all phone device control protocols without major modifications. Thus an alternative needs to be found for supporting phone device control protocols for PBXs or Feature Servers (also known as Call Processing Servers), and the features and devices supported by these protocols, which often offer a broader and/or more customized set of features than are available via typical SBC supported protocols (which typically are limited to SIP, MGCP or H.323). In this specification, the term Feature Server (FS) includes suitably configured PBXs.
Furthermore, the nature of VoIP signaling protocols and the fact that RTP endpoint identifiers are not always captured at the same point in call establishment makes direct protocol conversion to a supported protocol limited even when possible. For example, converting between protocols will often result in only the features common between the two protocols surviving the conversion. Furthermore, direct conversion can only be implemented for a specific protocol, and sometimes different protocols are desired because they offer different features. Even in the case where protocol conversion is implemented there are features that are necessary to deliver a phone service that might not survive the conversion. As one example, when numbers are dialed by a device using some IP PBX stimulus protocols, the digits are sent one at a time and the application server is responsible for determining when the full number has been dialed. With a SIP phone, the user presses “OK” or “Send” at the end of the number and the whole number is sent in one message. Performing the “conversion” then requires the “converter” to be aware of dial plans, etc, which involved much more than protocol conversion and is often impractical.
Additional problems arise when only some of the phones are deployed behind NATs while others are not, as a solution that unnecessarily uses network resources should be avoided.
Additional complications and opportunities for optimization exist when a mixture of devices using proprietary protocols and SBC-supported standard protocols are used.
It is desired that the Feature Server retain knowledge of the network topology, specifically of the LAN at which the phones are located. This allows for the detection of calls between phones behind the same NAT as well as to allow the delivery of “site-specific” features.
It is, therefore, desirable to obviate or mitigate at least one disadvantage of previous solutions to the NAT traversal problem, while providing a full feature set to devices behind a NAT.